Many communications protocols are based on the transmission and reception of information coded into so-called ‘packets’. Such packets consist of a number of defined fields, and the protocol defines the content of such fields for transmitting a particular item of data. An important part of communication equipment is therefore an apparatus for constructing and deconstructing such packets.
As an example, some of the different packet types for the Bluetooth® standard are shown in FIG. 1. The packets begin with an access code field which allows the receiver to discriminate the beginning of the transmission. This carries no other information content. The packets also include a header field: amongst other things, this identifies the type of packet. This part of the packet is protected against transmission errors with a rate 1/3 error correcting code (FEC), and remaining errors are detected by an 8-bit CRC check.
What follows next then depends on the type of packet: for packet types Null and Poll, there is no other information. For other packet types, there are one or more subsequent information fields carrying different types of data.
Depending on packet type, these are encoded with different types of error correcting codes and may or may not contain a CRC field to check for errors. The length (number of bytes) of subsequent fields may be defined by the packet type (e.g. HVx packet types), may be pre-defined by some prior negotiation (e.g EVx packet types), or may be variable and defined by a further information field (e.g. the payload header for packet types with a data payload).
The apparatus for constructing and deconstructing such packets must therefore be capable of supporting a number of different coding formats. Particularly in the receive direction, there are often hard real time constraints and it is necessary to rapidly interpret the contents of one information field in order to re-configure the packet deconstruction apparatus to process the following sections. Due to the time constraints, and also due to the requirements for low power consumption for portable data communication systems such as Bluetooth®, it is common to design a dedicated hardware packet processing datapath block for performing the bit-level operations.
Communication standards are always in a state of rapid evolution, and the pressure to achieve a fast time-to-market for updated versions of a standard requires that a communications product be designed with flexibility in mind. Typically, this is achieved by having the key decision-making processes performed by software running on a general purpose micro-processor embedded in the communications product. An update to the standard (e.g. a new packet type) can then often be catered for by a pure software upgrade. This also provides for protection against errors in design, since hardware errors in the packet processing datapath can often be corrected by intervention from the microprocessor via a work-around in the software.
A simple example of such a system 10 is shown in FIG. 2. This comprises a microprocessor 12 with its own bus system 14, 16 and a packet processing datapath 18 consisting of an RF interface 181 (which transfers data to and from the radio), a FEC block 182 (which performs error correction coding or decoding), a CRC block 183 (which generates or checks a CRC code) and a DMA endpoint 184 (which requests that information bytes be transferred to or from system memory via direct memory access, and issues an interrupt to the processor when the required number of bytes have been transferred).
Respective block in the packet processing datapath 18 communicates with its neighbors, and contains configuration registers which provide information on what operation the block should perform for the current packet field being processed. An example of a possible register definition for the simple example datapath is shown in FIG. 3. It should be noted that a practical implementation is likely to contain both more functional blocks and more configuration registers per block. The packet processing datapath 18 is attached to the bus as a slave via a bus 14 interface block 16. This decodes the bus protocol and performs write or read operations to the configuration registers.
For the case of reception of Bluetooth® packets, the microprocessor would first configure the datapath for reception of the header field. For the simple example datapath, this would require 7 programming operations over the microprocessor bus. The Bit_Count field for the RF interface would be programmed last, since this would have the side-effect of causing data to begin to flow through the datapath. Once the header is received, the microprocessor would receive an interrupt from the end-point. It would then read the packet type from the header. Depending on the packet type, it would be necessary to reprogram some or all of the registers for the subsequent field, and repeat this for every subsequent field. For example, a DH1 packet would first require that the datapath be programmed to receive the payload header. Then, the datapath would need to be reprogrammed to receive the payload body.
The example datapath has a fairly trivial number of configuration registers. In a practical hardware implementation there are likely to be considerably more registers. Also, there may be a number of wait states introduced in gaining access to the registers. This means that such reprogramming can take a significant amount of time (from the system viewpoint). As mentioned previously, decisions during reception are often time-critical. The time taken to do the reprogramming means that there is less time left and therefore there is less flexibility to implement software work-arounds. The alternative is to increase the clock frequency to reduce the time taken, which has an effect on system power consumption.
Additionally, a microprocessor (and associated ROM and RAM memories) consumes significant amounts of energy when active. Typically, in an event-driven system such as that described, the processor will be shut down when there are no tasks to perform and will consume almost no energy. Once the “intelligence” of the microprocessor has been used to make a decision about what type of field is to come next, it is wasteful of energy for the processor to perform the manual process of updating respective of the registers.